Without the data it's guessing. But consider this, why would ANet not have randomized it long before and in stead chosen a selection algorithm that apparantly makes syncing possible?
This.
As usual on these forums, we're just guessing and playing the developer, throwing assumptions and pretending we know how the game actually works and what the priorities during the development process were.
Developers sure know better than us what's the best solution: likely the devteam thinks it's better to allow some (admitedly difficult) syncing than implementing 100% randomization, increasing the wait times for everyone in the queue.
Developers sure know better than us what's the best solution: likely the devteam thinks it's better to allow some (admitedly difficult) syncing than implementing 100% randomization, increasing the wait times for everyone in the queue.
I'd agree with you if it weren't mathematically demonstrable that the average increase in wait times would be minimal.
The change in average expected timer wait (given the above assumptions with existing winners pairing off) is given by something less than 1/1225 + 1/20825 ~= 0.0008+0.000048 = 0.000848. So if your average wait is now 1.1, then your new average wait is less than 1.100848. (Yes, I'm being a bit lazy with prob/stat.)
(Note that the expected chance of drawing a single NOP does not vary.)
The effect is negligible. You can inflate the chances a bit by playing with the assumptions, but you're not getting the expected number of timers up to 1.11 with anything that remotely reflects current activity.
If RA became horribly inactive, I think that the worst case scenario in terms of differential approaches 0.5. I'd have to go grab a math book, pencil and paper to solve the infinite series case, though. Social choice deals with the finite more often than not, so I can't do it in my head.
As usual on these forums, we're just guessing and playing the developer, throwing assumptions and pretending we know how the game actually works and what the priorities during the development process were.
Developers sure know better than us what's the best solution: likely the devteam thinks it's better to allow some (admitedly difficult) syncing than implementing 100% randomization, increasing the wait times for everyone in the queue.
Lost the thread right here.
If the devs knew better then us:
Factions wouldn't have happened.
Nightfall wouldn't have happened.
VoD wouldn't have happened.
Redicilous buffs wouldn't have happened.
PvP crumbling woudn't have happened to this redicilous extend.
Complete split between PvP and PvE wouldn't have happened.
And so much more. The reason why RA hasn't been fix'ed yet simply is because they don't know any better. Lemming's suggestion combined with my "fix" would solve every form of RA syncing, would in no way be abusable (UNLESS you're the only team going in, but then there simply is not a single thing you can do to prevent this.)
You wouldn't have insane long wait times, I really have no clue what you're talking about. What are the odds of waiting longer than 120 seconds (3 resets): 0 or next to 0%. Why? Because the second you hit the third reset, the game will put you on a priority list, exactly how RA works now, (spot nr 1) and unless the game doesn't find 3 other players for you to team up with, you'll always go in on the 4th try. And if you don't, that's solely because the format is inactive, and not because the suggested solution sucks.
Or maybe you can post here how exactly the game is supposed to form a 4 man team when there's only 1 person (in the intire game) waiting in RA to go in.
The reason why RA hasn't been fix'ed yet simply is because they don't know any better.
Really? People are getting way too overconfident here. Lemming's solution is so obvious that I though it was how the current team formation worked at first.
Do you really think Anet is so inept they couldn't think of it by themselves?
Do YOU really think you know better than people working full time on their games, who most of the time have a significant experience in the field? Have you ever thought that MAYBE they've evaluated multiple possibilities and discarded this one for some issues you don't know - like, difficult implementation, side effects, or whatever?
It's not you nor me to judge wether their priorities and their motivations behind prefereces are right or wrong.
Quote:
Originally Posted by Killed u man
You wouldn't have insane long wait times, I really have no clue what you're talking about. What are the odds of waiting longer than 120 seconds (3 resets): 0 or next to 0%. Why? Because the second you hit the third reset, the game will put you on a priority list, exactly how RA works now, (spot nr 1) and unless the game doesn't find 3 other players for you to team up with, you'll always go in on the 4th try. And if you don't, that's solely because the format is inactive, and not because the suggested solution sucks.
That's if there some form of prioritization as you're suggesting - while Martin thinks it useless. Otherwise, you could spend a whole day waiting for the random algorithm to pick YOU up among thousands of players in the queue.
Last edited by Gill Halendt; Jun 16, 2010 at 08:58 PM // 20:58..
Yes, that's theoratically possible. It's also possible you get hit by a meteor the next time you take a walk outside. (Doesn't even have to be outside lulz)
For that to happen, you'e assuming alot of things. Too much to mention, but pretty much that you're always part of the few people (<7) who never gets formed up.
And we don't know the exact numbers, but if there's 40 people going in, which seems a very reasonable amount given the amount of people in the many districts, the chances are less than 1%. (As Martin pointed out)
Really? People are getting way too overconfident here. Lemming's solution is so obvious that I though it was how the current team formation worked at first.
Do you really think Anet is so inept they couldn't think of it by themselves?
Do YOU really think you know better than people working full time on their games, who most of the time have a significant experience in the field? Have you ever thought that MAYBE they've evaluated multiple possibilities and discarded this one for some issues you don't know - like, difficult implementation, side effects, or whatever?
Reconnects.
Quote:
Originally Posted by Gill Halendt
That's if there some form of prioritization as you're suggesting - while Martin thinks it useless. Otherwise, you could spend a whole day waiting for the random algorithm to pick YOU up among thousands of players in the queue.
What are the odds that you're going to be shafted more than once or twice in a queue of thousands?
What are the odds that you're going to be shafted more than once or twice in a queue of thousands?
Depends on how many teams are formed every given time interval.
If the number is low, the odds are fairly high, expecially since the cue is open-ended and still allows more people to click the Enter button and join the queue any time. Unless you process it in order, you have no certainty at all that you'll ever be picked up. Some prioritization system is necessary.
Developers sure know better than us what's the best solution
theres a reason why developers hire play testers (i.e. test krewe)
Quote:
Do YOU really think you know better than people working full time on their games
theres a great amount of understanding one can obtain through playing a game that one cannot obtain by developing it. you talk about experience--collectively the players have way more playing experience than the devs do; many decisions the devs make are based on (limited) analysis and theorycrafting.
Depends on how many teams are formed every given time interval.
If the number is low, the odds are fairly high, expecially since the cue is open-ended and still allows more people to click the Enter button and join the queue any time. Unless you process it in order, you have no certainty at all that you'll ever be picked up. Some prioritization system is necessary.
Let's say that at zero seconds on the countdown, there's 101 people in the queue and that no team currently in RA had a member leave.
The chance that you're the one guy left over is 1/101.
What are the odds that you're going to be shafted more than once or twice in a queue of thousands?
That somewhat depends on the size of the batch that is dequeued every period.
Quote:
Originally Posted by lemming
Let's say that at zero seconds on the countdown, there's 101 people in the queue and that no team currently in RA had a member leave.
The chance that you're the one guy left over is 1/101.
If you're saying that each (30 second) period teams are formed until there aren't enough players left for a match then there would be no problem with syncing, provided assignment of players to teams is random - and I don't see why that wouldn't be the case. Otoh, if, like foxbat claims, there aren't enough players to distribute syncers over different teams, so it looks like the 101 would rather be something like 20, or less.
Quote:
Originally Posted by Martin Alvito
... but the chances of such waits are so negligible (much less ever experiencing multiple such waits) that they aren't really worth our consideration when trying to solve this problem of social choice.
Do you have a method that allows calculating the chance of a long wait without knowing anything about how many players are queued or how many arena's are available every period? How can you claim such chances are negligible without data?
Quote:
Originally Posted by Martin Alvito
The change in average expected timer wait ...
The change, if any, in average waiting time is not the expected problem, but the occurence of the more extreme waiting times that might cause players to leave. Which is something to take into account.
The 'priority queue' introduced earlier seems to address both issues.
Quote:
Originally Posted by Martin Alvito
... I don't have to treat you with respect when you mischaracterize my statements.
You have been disrespectfull towards me from your very first reaction on me. Your first reaction to me, this
Quote:
Originally Posted by Martin Alvito
... Look up what "variance" means.
is where you added a personal touch and there was really no need for that. Now, where did I "mischaracterize" your statements? Don't ramble about 'respect' or 'playing nice' when you started the bickering but stop pretending you didn't.
you talk about experience--collectively the players have way more playing experience than the devs do; many decisions the devs make are based on (limited) analysis and theorycrafting.
You talk about theorycrafting and forget that this whole thread is based on assumptions an empirical observations. Also experience is not to be considered collectively.
You also seem to forget that the player's needs are not the only ones to be taken into account. Reworking algorithms is a tricky process. Suggestions made here might look perfectly fine and logical from the player's point of view, but still they're not for the developer. I wouldn't be surprised to get a reply such as "This solution was cheaper and quicker to develop given the limited resources we have at our disposal". From the player's point of view, the solution implemented is an obvious improvement but still it's not optimal, but the developer is fine with it and won't bother going further. It's called compromise, which is a pretty common practice in every development process.
Quote:
Originally Posted by lemming
Let's say that at zero seconds on the countdown, there's 101 people in the queue and that no team currently in RA had a member leave.
The chance that you're the one guy left over is 1/101.
So, that's around 1%, which is fairly high, considering that the number of players in the queue is dynamic and likely much higher. That one guy has no certainty to be in the next batch unless you process the queue in order or shift him to be high-prioritized for the next batch.
Last edited by Gill Halendt; Jun 16, 2010 at 10:43 PM // 22:43..
So, that's around 1%, which is fairly high, considering that the number of players in the queue is dynamic and likely much higher. That one guy has no certainty to be in the next batch unless you process the queue in order or shift him to be high-prioritized for the next batch.
Assuming an even rate of players joining the queue, you have a better chance of winning a lottery than waiting even two minutes.
Assuming an even rate of players joining the queue, you have a better chance of winning a lottery than waiting even two minutes.
Don't think so, your suggestion introduces randomization at every level. Since we don't know how many teams are formed for every countdown and the average number of player trying to get in at the same time, processing the queue in order still looks more viable, as it forms teams based on the age rank of each member in the queue, a factor your suggestion as-is is completely ignoring.
I also don't see a reason why a user shouldn't be prioritized after multiple failed attempts at joining the game. It makes perfect sense.
How can you claim such chances are negligible without data?
Lemming just answered that for you. This is an elementary prob/stat problem. You can increase the odds of waiting multiple timers if you reduce the hypothetical number of players entering at any time, but you can't force the odds to be significant unless the number of players on the server is very small (in which case you're waiting anyway).
Quote:
Originally Posted by Amy Awien
The change, if any, in average waiting time is not the expected problem, but the occurence of the more extreme waiting times that might cause players to leave. Which is something to take into account.
The 'priority queue' introduced earlier seems to address both issues.
Since Borat has clarified what he meant, I agree that adding a priority trigger to Lemming's queue is a good addition. But it really isn't all that necessary, except for a dead arena.
Quote:
Originally Posted by Amy Awien
Now, where did I "mischaracterize" your statements?
I said:
Quote:
Originally Posted by Martin Alvito
This will not affect the average time necessary to get a match by much.
It will increase the variance in your wait times.
You said:
Quote:
Originally Posted by Amy Awien
That was not the point, which was that true randomness will mean that sometimes people will have to wait much longer.
The clear implication is that you don't understand what "variance" means. Hence the admonition to look it up. That's not a personal attack. It's simply clear from your response to my post (and your subsequent insistence that you're correct) that you don't understand the concept even if you think you do.
I've lost patience with you because you've repeatedly insisted that I ignored the point you are trying to make. But I accounted for that point (and rightly dismissed its importance) from the get go.
This whole thread is pointless. Anyone with common sense would have known syncing isn't against the ToS and is not punishable due to the fact all u have to do is countdown in chat or on vent/ts. Stop the QQ and get 3 friends and sync yourself. BTW I have achieved r2 without syncing at all so you really have no case.
Last edited by Da Bears; Jun 16, 2010 at 11:35 PM // 23:35..
Don't think so, your suggestion introduces randomization at every level. Since we don't know how many teams are formed for every countdown and the average number of player trying to get in at the same time, processing the queue in order still looks more viable, as it forms teams based on the age rank of each member in the queue, a factor your suggestion as-is is completely ignoring.
Judging from the fact that pressing the enter button in RA at basically any hour almost always gives a match at the end of the countdown, it's a reasonably safe assumption that the queue fills as many teams as possible.
Quote:
Originally Posted by Gill Halendt
I also don't see a reason why a user shouldn't be prioritized after multiple failed attempts at joining the game. It makes perfect sense.
I'm not saying it shouldn't, I'm merely saying that it's nowhere near as relevant in Random Arenas as you're making it out to be.
Judging from the fact that pressing the enter button in RA at basically any hour almost always gives a match at the end of the countdown, it's a reasonably safe assumption that the queue fills as many teams as possible.
If this is the case and they create as many teams/arena's to assign almost everyone one could just prioritize the remaining players, and then spread them over several teams in the next round.
If there are only enough players to fill a few teams every round you will see synced teams, even with random assignment.
Quote:
Originally Posted by Martin Alvito
Lemming just answered that for you.
No, he didn't. he pulled a number from thin air.
Quote:
The clear implication is that you don't understand what "variance"
No, no, no, you were being nasty, if you'd truly believed I didn't know the word you'd have used half a sentence to explain it. Not to mention there's enough math from me floating this forum to indicate I would likely know it.
In the future, just be less stingy in your remarks and limit yourself to the actual points in the discussion, that will help you prevent making such mistakes.
Quote:
I've lost patience with you because you've repeatedly insisted that I ignored the point you are trying to make. But I accounted for that point (and rightly dismissed its importance) from the get go.
No, you ignore the point when you start to argue about 'average' waiting time, where the point is that an extremely long waiting time will have a more impact on perception then the 'average' time. You then claim, without any evidence, that the chance of (extremely) long waiting times is negligible.
You then claim, without any evidence, that the chance of (extremely) long waiting times is negligible.
Well, it probably is for players, for the sake of voiding syncing.
It's likely not negligible for ANet that rather chose to process the queue in order, First Come-First Served/FIFO style, as observed.
This kind of approach is pretty common, simple to implement and offers no unfairness in the processing of the queue and high performance/quality of service, which is likely why they chose this instead of a full randomization, which usually affects processing performance significantly.
If the negative effect of syncing exceeds that of an occasional long wait then the choice for the longer wait would be reasonable.
If you have as many arena's as needed to empty the queue then implementing randomization of assignment to teams while maintaining a FIFO is not so hard - and it would have negligable impact on performance.